style="width:8.00694in;height:3.84722in" /> 本文是学习GB-T 33736-2017 手机支付 基于2.45GHz RCC 限域通信 技术的非接触射频接口技术要求. 而整理的学习笔记,分享出来希望更多人受益,如果存在侵权请及时联系我们
磁通道数据链路层帧分为逻辑帧、物理帧，如图9所示。逻辑帧定义了磁通道数据的逻辑结构，通
GB/T 33736—2017
过对逻辑帧数据进行位填充，并增加同步码形成在磁通道上传输的物理帧。
|
||
|---|---|---|
|
|
|
图 9 逻辑帧和物理帧的关系
7.1.2.1 同步码
用于磁通道数据帧同步的位序列；字段长度：9比特；同步码的值为：111111110b。
7.1.2.2 位填充码
从逻辑帧起始处开始向后检索，出现位流1111111b
时，填充1位"0"形成11111110b。
7.1.2.3 物理帧帧间空闲
如果在磁通道上任意两个有效物理帧位流之间存在空闲时间间隔，则发起方应发送全"1"比特流填
充序列。
7.1.3.1 MCF 帧结构
MCF
采用变长编码格式，其帧结构包括：控制域(包括帧类型、帧数据长度)、MCF
数据域、CRC 校
验，如图10所示。
style="width:8.00694in;height:3.84722in" />
图10 MCF 帧格式
7.1.3.2 MCF 控制域
MCF 控制域如表4所示。
GB/T 33736—2017
表 4 MCF 控制域
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|
|
|
7.1.3.3 MCF 数据域
MCF 数据域如表5所示。
表 5 MCF 数据域
|
|
|
|
|---|---|---|---|
|
|
|
|
7.1.3.4 MCF 校验
MCF 校验如表6所示。
表 6 MCF 校验
|
|
|
|
|---|---|---|---|
|
|
|
|
7.2.1.1 RCF 帧结构
RCF
采用变长编码格式，其帧结构包括：前导码、地址、控制域(包括数据长度、帧标识、应答标识)、
数据域、CRC 校验，如图11所示。
GB/T 33736—2017
|
|
|
|
|
||
|---|---|---|---|---|---|---|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
图11 RCF 编码格式
7.2.1.2 RCF 前导域
RCF 前导域如表7所示。
表 7 RCF 前导域
|
|
|
|
|---|---|---|---|
|
|
|
|
|
7.2.1.3 RCF 地址域
RCF 地址域如表8所示。
表 8 RCF 地址域
|
|
|
|
|---|---|---|---|
|
|
|
|
RCF 控制域如表9所示。
表 9 RCF 控制域
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 33736—2017
7.2.1.4 RCF 数据域
RCF 数据域如表10所示。
表10 RCF 数据域
|
|
|
|
|---|---|---|---|
|
|
|
|
7.2.1.5 RCF 校验
RCF 校验如表11所示。
表11
style="width:0.55995in;height:0.5467in" />
RCF 校验
|
|
|
|
|---|---|---|---|
|
|
|
|
7.2.2.1 数据帧
按 RCF 帧结构编码，其中AckFlag 为1,表示需要 RCF 的接收方自动发送一个
ACK。
7.2.2.2 应答帧
按 RCF 帧结构编码，其中 RF DataLen 为 0 ,AckFlag 为0,无RF Data。
7.2.3.1 组帧
RCF
组帧过程如图12所示。按照规定的帧结构将数据组织在一起形成一个帧，并经过物理层处
理后形成射频信号，然后进行发送。帧的发送顺序为最先发送前导域，最后发送CRC
校验域。
7.2.3.2 解帧
RCF
解帧过程如图13所示。将物理层接收到的射频信号解调成数字单比特信号后，按照帧结构
进行解析，解出有效的帧数据。
GB/T 33736—2017
style="width:2.56042in;height:16.03403in" />
图 1 2 组帧过程
GB/T 33736—2017
style="width:2.86736in;height:16.82014in" />
style="width:2.86736in;height:16.82014in" />
图13 解帧过程
GB/T 33736—2017
7.2.4.1 帧收发时序图
style="width:9.45347in;height:4.02917in" />
style="width:0.13326in;height:0.15334in" />
图14 射频帧收发处理时序图
7.2.4.2 发射-接收转换时间
发送方在完成数据帧发送后，应在t₁ 时间内切换到应答帧接收状态(t₁ ≤130
μs)。
7.2.4.3 接收-应答转换时间
接收方在收到一个数据帧后，应在t₂
时间内发送一个应答帧进行响应(130μs\<t₂ \<150 μs)。
7.2.4.4 帧传输
帧的传输过程包括一个数据帧发送和一个应答帧接收。发送方发送一个数据帧，并在t₁
时间内切
换到应答帧接收状态，如果成功接收到应答帧，则判断一次帧传输成功。如果未接收到应答帧则判断帧
传输失败。帧的发送处理过程如图15所示。
接收方在收到相同的数据帧后，应当丢弃并继续接收。帧的接收处理过程如图16所示。
style="width:6.26667in;height:12.18056in" />
图 1 5 帧的发送处理
GB/T 33736—2017
GB/T 33736—2017
style="width:5.67361in;height:11.44028in" />
图16 帧的接收处理
MCP 采用变长编码格式，包括 MCP 头和 MCP 数据两个部分，如图17所示。
GB/T 33736—2017
|
|
|---|
图17 MCP 编码格式
MCP 头如表12所示。
表12 MCP 头
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|||
|
|||
|
|||
|
MCP 数据域如表13所示。
表13 MCP 数据域
|
|
|
|
|---|---|---|---|
|
1～ 14 |
|
|
RCP 采用变长编码格式，包括 RCP 头和 RCP 数据两个部分，如图18所示。
GB/T 33736—2017
|
|
|---|
图18 RCP 编码格式
RCP 头如表14所示。
表14 RCP 头
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|||
|
|||
|
RCP 数据域如表15所示。
表15 RCP 数据域
|
|
|
|
|---|---|---|---|
|
1～ 31 |
|
|
采用顺序分包方式传递一个 MCMe 消息或 RCM 消息。
首包序号为0,发送方从首包开始按包序号递增顺序逐包发送，接收方收到数据包后按顺序重新组
合成一个完整的消息。
消息分包方式如图19所示。
|
|
|
|
|
|
|---|
图19 协议消息的分包方式
包的发送处理过程如图20所示。
GB/T 33736—2017
style="width:7.78056in;height:11.86042in" />
图20 包的发送处理
接收方收到数据包后按顺序重新组合成一个完整的消息。
接收方收到的 RCP 包与当前已收到的RCP
包的包号相同时，应当丢弃并继续接收。
包的接收处理过程如图21所示。
GB/T 33736—2017
style="width:6.52666in;height:11.09988in" />开始接收
是
接收超时?
否
是
包号重复? 丢弃该包
否
否
包号正确?
是
解出包数据块
否
末包?
是
组合成消息
结束
图21 包的接收处理
短消息格式(SMF) 用于传输 MCM 消息。 SMF 格式如图22所示。
GB/T 33736—2017
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
||
图22 SMF 格式
SMF 消息头如表16所示。
表16 SMF 消息头
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
SMF 消息体如表17所示。
表17 SMF 消息体
|
|
|
|
|---|---|---|---|
|
|
|
|
长消息格式(LMF) 用于传输 RCM 消息和 MCMe 消息。 LMF 格式如图23所示。
|
|
|
||||
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
图 2 3 LMF 格式
LMF 消息头如表18所示。
GB/T 33736—2017
表18 LMF 消息头
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|||
|
|||
|
|
|
|
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|
|
|
|
|
|
LMF 消息体如表19所示。
表19 LMF 消息体
|
|
|
|
|---|---|---|---|
|
|
|
|
LMF 消息校验如表20所示。
表20 LMF 消息校验
|
|
|
|
|---|---|---|---|
|
|
|
|
本标准定义的消息码如表21所示。
表21 消息码定义
|
|
|
|
|
|---|---|---|---|---|
|
||||
|
|
|
|
|
GB/T 33736—2017
表21 (续)
|
|
|
|
|
|---|---|---|---|---|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
||
|
|
|
||
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
||
发起方与响应方之间的基本通信会话流程如图24所示。
发起方在连接和交易过程中应维持磁场存在，响应方在发送任何响应之前，应确定其处于设定的磁
场强度范围内。
会话层消息的发送方在消息发送完成后应当立即转换为消息接收状态，并按照会话命令规定的时
间内进行接收。
GB/T 33736—2017
style="width:12.34673in;height:10.39346in" />发起方
INQUIRY
CONNECT REQ
响应方2
响应方
发起方半次交易性一识别信总 IDm
磁通道
响应方随机IDs及物理标识码TargetID
ATI
RF送道(按热IDm 设置物埋工作频点及趋信配置地址)
确认接入接收信息、发起方物理InitiatorlD
RF还道(按照IDs设置物进工作频点及通位配置地址)
角认接入信息
RF近送(按照IDs没置物斗工作频点及通信配置地址)
激活阶段：
接收磁信道消息并激 活 RF证道
接入阶段：
磁场强度范用 内建立连接
方冲突
CHECK1 RSP
名
style="width:1.31342in;height:0.75988in" />
冲突俭测请求号CDC
磁通道
链路密文数据
RF通道(按照IDs设置物理工作频点及通信配置地址)
交易介段：
链路密文数据
APDATA RSP
RF通道(按照IDs设置物理工作频点及通信配置地址)
rrr
维持连按请求
RF通道(按照IDs设置物理工作频点及通信配置地址)
维持连接响应
LINKCTL RSP
RF通逆(按照IDs设置物律工作频点及通信配置地址)
style="width:0.1866in" />
链路密文数据
RF通逆(按照IDs设置物理工作频点及通信配置地址)
链路密文数据
RF通道(按照IDs设置物理工作频点及通信配置地址)
aOSEa
关闭连接
RF通送(按照IDs设置物甲工作频点及通信配置地址)
关闭响应
RF通道(按照IDs没置物涩工件频点及通信配置地址)
结束，断开链接
CLOSE RSP
_
图24 基本会话流程
协议会话的工作流程通常包括激活、接入、交易、结束四个阶段。
激活阶段各操作如下：
发起方操作：
● 发起方在激活阶段通过磁通道发送 INQUIRY, 然 后 通 过 RF 通 道 接 收
ATI。
● 发起方在发送 INQUIRY 之前，根据自己生成的 IDm 计算激活响应(ATI)
频点并确认该频点 是否可用，如果该频点当前已被占用，则需要重新生成 IDm
直到选择的 ATI 频点空闲为止。
● 发起方如果接收到错误的 ATI 、或 者 ATI 中 的 Mac
验证失败、或者接收超时(>8 ms), 则 发送新的 INQUIRY。
● 发起方在接收到第 一 个正确的 ATI 之后进入接入阶段。
响应方操作：
● 响应方在激活阶段通过磁通道接收 INQUIRY, 然 后 通 过 RF 通道发送
ATI。
● 响应方如果接收到错误的 INQUIRY 或者未接收到 INQUIRY, 则继续接收
INQUIRY。
● 响应方在接收到第 一 个正确的 INQUIRY 之后被激活，然后在8 ms 内 通 过
RF 通 道 做 出
ATI 响 应 。
GB/T 33736—2017
● 响 应 方 在 发 送 ATI 之前，根据自己生成的 IDs
计算后续接入/交易频点并确认该频点是否可
用，如果该频点当前已被占用，则需要重新生成 IDs
直到选择的接入/交易频点空闲为止。
● 响 应 方 在 发 送 完 ATI 之 后 进 入 接 入 阶 段 。
— 处 理 流 程 ：
激 活 阶 段 处 理 流 程 如 图 2 5 所 示 。
发起方 响应方
style="width:8.95998in;height:9.10008in" />空闲
空闲
发送
INQUIRY
消息
接收
All
消息
收到
INQUIR Y
消 息 》
是
否
否
收到
CHECK1 REQ
消 息 ?
是
否 8ms 内收到
ATI消息?
发送
ATI
消息
冲突处理机制
是
否
MAC 验证
正确?
是
接入阶段
接入阶段
图 2 5 激 活 阶 段 处 理 流
程
接入阶段各操作如下 ：
— 发 起 方 操 作 ：
● 发 起 方 在 接 入 阶 段 通 过 RF 通 道 发 出CONNECT REQ
连接请求，然后通过 RF 通 道 接 收 CONNECT RSP 响 应 。
● 发 起 方 如 果 接 收 到 错 误 的 CONNECT RSP 或 者 接 收 超 时 ( >
8 ms), 则 返 回 激 活 阶 段 。
● 发 起 方 在 接 收 到 第 一 个 正 确 的 CONNECT RSP 之 后 进 入 交 易
阶 段 。 _
响 应 方 操 作 ：
● 响 应 方 在 接 入 阶 段 通 过 RF 通 道 接 收 CONNECT REQ, 然 后 通
过 RF 通 道 发 送 CONNECT RSP 进 行 响 应 。
● 响 应 方 如 果 接 收 到 错 误 的 CONNECT REQ 或 者 接 收 超 时 ( > 8
ms), 则 返 回 到 激 活 阶 段 。
GB/T 33736—2017
● 响 应 方 在 发 送 完 CONNECT RSP 之后进入交易阶段。 _
——处理流程：
接入阶段处理流程如图26所示。
发起方
style="width:10.69332in;height:10.4599in" />接入阶段
发送
CONNECT RHQ
消息
响应方
接入阶段
CQNNECT REQ
消息?
否
是
接收
CONNECT RSP
消息
发送
CONNECT RSP
_
消息
激活阶段
CONNECT
消息?
是
激活阶段
否
连接成功?
合法连接?
否
足 是
交易阶段
交易阶段
图26 接入阶段处理流程
9.2.4.1 数据交换
数据交换各操作如下：
— 发起方操作：
● 发起方在交易阶段通过 RF 通 道 发 送 APDATA REQ 数据交换请求，然后通过
RF 通 道
接收 APDATA RSP 响应或者 LTW 长时等待消息。
● 发 起 方 如 果 接 收 到 错 误 的 APDATA RSP/LTW 阶段。
● 发起方如果接收到正确的 APDATA RSP/LTW,
_
或 者 接 收 超 时 ( > 5 0 0 ms), 则 返 回 激 活
则继续维持交易阶段。
GB/T 33736—2017
响应方操作：
● 响应方在交易阶段等待接收 APDATA REQ, 解析和执行封装在 APDATA REQ 中
的 APDU 命令，然后把对 APDU 命令的响应封装在 APDATA RSP
中发送给发起方。
● 响应方如果接收到错误的 APDATA REQ 或者接收超时(>100 ms),
则返回激活阶段。
● 响应方应该在500 ms 内发送 APDATA RSP, 或 者 LTW
长时等待消息给发起方。
● 响应方在发送完 APDATA RSP 或 LTW 后，继续维持交易阶段。 _
— 处理流程：
数据交换处理流程如图27所示。
style="width:12.13339in;height:12.54682in" />发起方 响应方
交易阶段
交易阶段
激活阶段
否
空闲超过44 ms?
是
维持链路处理
有APDU
数据?
是
发送
APDATA RF()
消总
接收
APTATA RSP
消息
100 ms内收到
|
|
|---|
转发APDATA
到应用处理
否
APDATA RSP
消息?
是
否
处理完成?
是
激活阶段
转发APDU 执行 结果到应用处理
是
消息状态
异常?
是
消息状态为0x02?
否
发送APDATA 异常响应消息 (状态：0x02)
是
发送
APDATA RSP
_
消息
结束阶段
结束阶段
图 2 7 数据交换处理流程
GB/T 33736—2017
9.2.4.2 链路维持
链路维持各操作如下：
— — 发起方操作：
● 发起方在交易阶段的空闲时间里应当每隔44 ms 通 过 RF 通道发送 LINKCTL
REQ, 然
后通过 RF 通道接收 LINKCTL RSP 以维持连接。
● 发起方在发送 LINKCTL REQ 后，如果在8 ms 内接收到正确的 LINKCTL RSP
响应且
响应方状态正常，则继续维持与响应方的连接；如果发起方连续10次在发送
LINKCTL
REQ 后均无法正确收到 LINKCTL RSP
响应则认为响应方已断开连接，发起方返回激活
阶段。
响 应方操作：
● 响应方在交易阶段，每次从 RF 通道接收到正确的 LINKCTL REQ
命令请求时，均应在
8 ms内发送 LINKCTL RSP 做出响应。
● 响应方在交易阶段，如果接收到正确的 LINKCTL REQ
命令请求，并确认磁通道已收到 CHECK1 REQ 或 者 CHECK2 REQ 消息，且 CDC
或 者 TRI 正确无误，则应当更新响应 方连接状态为正常，并在8 ms 内发送
LINKCTL RSP 做出响应。
● 响应方在交易阶段，如果连续三次接收到正确的 LINKCTL REQ
命令请求而没有收到任 何 CHECK1 REQ 或 者 CHECK2 REQ
消息，则应当更新响应方连接状态为异常，并在
8 ms内发送 LINKCTL RSP 做出响应。
● 响应方如果接收到错误的 LINKCTL REQ, 或者超过100 ms
仍未接收到任何命令，则响
应方返回激活阶段。
— — 处理流程：
链路维持处理流程如图28所示。
GB/T 33736—2017
发起方
响应方
style="width:12.29324in;height:13.3067in" />交易阶段
交易阶段
冲突检测
使能?
是
启动发送
CHECK1 REQ
消息
发送
APDATA RTQ
消息
否
空闲时间 超过44 ms?
LINKCTL REQ
L.INKC' RSP
|
否
|
|---|
否
接收消息
100msA
收到消息?
是
LNKCT. REO
消息?
是
收到
CHECK1/2 RTO
_
消 息 ?
是
发送
IINKCTL. RSP
消息
距离异常
是 连续次数\<109
否
次数增加1
发送异常
LINKCTL RSP
消总
激活阶段
结束阶段
图28 链路维持处理流程
9.2.4.3 冲突检测
当发起方检测到 MTC
冲突发生时，发起方不能进行任意一个响应接入，且应结束与当前响应方的
连接。 MTC 冲突如图29所示。各操作如下：
GB/T 33736—2017
style="width:8.13996in;height:5.00016in" />发起方1
CHECK REQ
响应方2
图 2 9 MTC 冲突
发起方操作：
● 发起方可以通过外部配置确定是否支持 MTC 冲突检测。
● 支持冲突检测的发起方在建立连接后的整个交易阶段通过磁通道持续发送
CHECK1 REQ 消息。
● 发起方建立连接后，在射频通道空闲期间(没有维持连接和 APDU 收 发 任 务
时 ) 以 t₂ (t₂ ≥4ms) 为 一
个最小接收时间单元，持续于冲突响应信道上接收 CHECK1 RSP
消息。
● 发 起 方 如 果 接 收 到 CHECK1 RSP, 并 且 其 中 TargetID 字 段 与 当
前 连 接 的 响 应 方 TargetID 不相符，则认为发生了 MTC 冲突。
● 当发起方检测到 MTC 冲突后，应当立即发送 CLOSE REQ
指令，结束与当前响应方的
连接。
响应方操作：
● 响应方在未连接状态下通过磁通道接收到CHECK1 REQ 消息则认为发生了MTC
冲突。
● 响应方两次收到 CHECK1 REQ 消息的最大时间间隔定义为 一 个冲突响应时间窗
T, 本
标准中 T=22 ms。
● 响应方检测到 MTC 冲突后，在冲突响应时间窗中，以 t₁
为冲突响应时间间隔(t₁ 最 大 为
4 ms)。t₁ 被划分为1个或多个响应时隙(每个时隙400μs)。 冲突响应方在t₁
时间内随机 选择 一个时隙发送冲突响应消息。冲突检测处理时序如图30所示。
● 冲突响应消息发送频点和地址由 CHECK1 REQ 消息中的CDC 字段决定。
style="width:10.33334in;height:3.49338in" />
图30 冲突检测处理时序
GB/T 33736—2017
处理流程：
冲突检测处理流程如图31所示。
style="width:10.17333in;height:7.76666in" />发起方
连接建立
冲突响应方
空闲状态
否
启动发送
CIIECK2 RCQ 消息
冲突检测
使能?
是
启动发送
CTECK1 RLQ
消息
收到
CTECK1 REO
消 息_ ?
是
选择发送时隙
接收t₂时间
CHECK RSP
消息
发送
CIIECK RSP
_
消息
重新开始计时
数据交换，或
链路维持
收到
CH消ECK息_RSP
是
发送
CLOSE RIQ
消息
否
数据交换，或
链路维持
是
是
发送成功?
否
冲 突 响 应 时
问 窗 超 时 ?
否
超出磁场
场 强 范
图 3 1 冲突检测处理流程
9.2.4.4 连接确认
连接确认各操作如下：
— 发起方操作：
● 如果冲突配置项为关闭，则发起方在整个交易阶段通过磁通道发送 CHECK2 REQ
连 接
确认请求。
—— 响应方操作：
● 如果响应方在交易阶段通过磁通道接收到 CHECK2 REQ 连接确认请求，则根据
TRI 是
否正确，相应地更新响应方的当前连接状态。该状态信息将在响应方下一条 RF
响应消息
中返回给发起方。
9.2.4.5 长时等待
长时等待各操作如下：
———发起方操作：
● 发起方在交易阶段等待响应方的 APDATA RSP
命令响应期间，如果接收到来自响应方 _
的正确的 LTW, 则继续等待500 ms, 直到接收到 APDATA RSP 或下 一 个 LTW,
或者接
收超时(>500 ms)。
● 发起方如果接收到错误的 LTW, 则返回激活阶段。
响应方操作：
● 响应方若不能在一个500 ms 时间内处理完成发起方的一个 APDATA REQ
中包含的命
GB/T 33736—2017
令请求，则应在500 ms 内通过 RF 通道向发起方发送一个LTW
长时等待消息，以通知发
起方再等待500 ms; 若响应方在下一个500 ms 内仍不能处理完成发起方的
APDATA
REQ 命令请求，则继续在每个500 ms 内发送一个LTW,
直到响应方处理完该交易后做出
APDATA RSP 响应为止。
● 响应方发送完LTW 之后，继续维持交易过程。
———处理流程：
长时等待处理流程如图32所示。
发起方
style="width:9.89328in;height:8.18004in" />发送
APDATA REQ
消息
响应方
接收
APDATA RFQ
消息
接收
APDATA RSP
/LTW
消息
收到消息?
是
转发APDU 到应用处理
否
收到消息
是
是
500 ms重新计时 LTW 消息?
否
否 连接断开
处理完成?
是
否 计时到 否
是
发送LTW 消息
转发APDU
到应用处理
发送
APDATA RSP
_
消息
图 3 2 长时等待处理流程
结束阶段各操作如下：
发 起 方 操 作 ：
● 如果发生下列情况之一，发起方必须通过 RF 通道发出 CLOSE REQ
关闭连接请求：
a) 交易正常结束；
b) 响应方状态不正常，即接收到的响应消息中的状态字段值不是0x00;
c) 发 生 MTC 冲突，即接收到CHECK1 RSP。
● 发起方应当在 CLOSE REQ
请求中对于是否要求响应方做出回应给出明确的指示。
● 发起方如果要求响应方回应，则继续等待，直到接收到 CLOSE RSP 或 接 收
超 时 _
(>500 ms)之后才返回激活阶段；否则发起方在发送完 CLOSE REQ
后立即返回激活
阶段。
响应方操作：
GB/T 33736—2017
● 响应方在接收到第一个正确的CLOSE REQ 后，应当立即结束交易，并根据
CLOSE
REQ 中的指示来决定是否发送 CLOSE RSP 响应。
● 如果发起方要求回应，则响应方应当在500 ms 内发送完CLOSE RSP,
然后返回激活
阶段；否则响应方在接收到 CLOSE REQ 后立即返回激活阶段。
处理流程：
结束阶段处理流程如图33所示。
发起方 响应方
style="width:8.92662in;height:9.19996in" />结束阶段
结束阶段
否
否
否
是
发送
CLOSE REQ
消息
需要响应?
是
接收
CLOSE RSP
_
消息
收到
CI.OSI RSP
是
CLOSE REQ
消息?
是
否
需要响应?
是
发送
CLOSE RSP
消息
激活阶段
激活阶段
图 3 3 结束阶段处理流程
会话命令通过发起方和响应方之间传递的消息来实现。表22为本标准定义的全部会话命令消息
集合。
表22 命令集
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
GB/T 33736—2017
表22 (续)
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
9.3.2.1 激活命令
9.3.2.1.1 INQUIRY
命令功能：查询并激活响应方。
传输信道：发起方通过磁通道发送 INQUIRY
消息格式：SMF
消息内容：见表23
表23 INQUIRY 消息
|
||||
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 33736—2017
9.3.2.1.2 ATI
命令功能：响应方对INQUIRY 的响应。
传输信道：响应方通过 RF 通道发送[频点=freq1(AID),地 址
=addrl(AID),freq1 和 addrl 的算
法定义见附录 B]。
消息格式：LMF
消息内容：见表24
表24 ATI 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.2 建立连接命令
9.3.2.2.1 CONNECT REQ
命令功能：发起方连接请求。发起方在发送 CONNECT REQ
消息之前，应首先验证 ATI 中 的
Mac 是否正确。发起方应在 CONNECT REQ
消息中指明本次连接中所希望采用的链路安全机制，包
括使用的根密钥、会话密钥生成方式，以及加密算法等。
GB/T 33736—2017
传输信道：发起方通过 RF 通道发送[频点=freq1(IDs),地 址
=addr2(IDs),freq1 和 addr2 的算法
定义见附录 B]。
消息格式：LMF
消息内容：见表25
表25 CONNECT REQ 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 33736—2017
表 2 5 ( 续)
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
表26 SessionKey: 会话密钥生成方式
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表27 EncAlg: 链路加密算法
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
9.3.2.2.2 CONNECT RSP
_
命令功能：响应方连接确认。响应方应在 CONNECT RSP
消息中确认本次连接中的链路安全机
制，包括根密钥使用、会话密钥生成方式以及加密算法的选择等。
传输信道：响应方通过RF 通道发送[频点=freq1(IDs),地 址
=addr2(IDs),freq1和 addr2 的算法
定义见附录 B]。
消息格式：LMF
GB/T 33736—2017
消息内容：见表28
表28 CONNECT RSP 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 33736—2017
表 2 8 ( 续)
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.3 数据交换命令
9.3.2.3.1 APDATA REQ
命令功能：发起方传递的应用层数据、命令。
传输信道：发起方通过 RF 通道发送[频点=freq1(IDs), 地 址
=addr2(IDs)freq1 和 addr2 的算法
定义见附录 B]。
消息格式：LMF
消息内容：见表29
表29 APDATA REQ 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 33736—2017
表29 (续)
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.3.2 APDATA RSP
命令功能：响应方对 APDATA REQ 的响应。
传输信道：响应方通过 RF 通道发送[频点=freq1(IDs),地 址
=addr2(IDs),freq1 和 addr2 的算法
定义见附录B]
消息格式：LMF
消息内容：见表30
表30 APDATA RSP 消息
|
||||
|---|---|---|---|---|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
||
9.3.2.4 维持连接命令
9.3.2.4.1 LINKCTL REQ
命令功能：发起方的链路维持请求。用于在链路空闲的状态下发起方与响应方进行连接状态的
确认。
GB/T 33736—2017
传输信道：发起方通过 RF 通道发送[频点=freq1(IDs),地 址
=addr2(IDs),freq1和 addr2 的算法
定义见附录 B]。
消息格式：LMF
消息内容：见表31
表 3 1 LINKCTL REQ 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.4.2 LINKCTL RSP
命令功能：响应方对发起方 LINKCTL REQ 命令的响应。
传输信道：响应方通过 RF 通道发送[频点=freq1(IDs),地 址
=addr2(IDs),freq1和 addr2 的算法
定义见附录 B]。
消息格式：LMF
消息内容：见表32
表32 LINKCTL RSP 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 33736—2017
表32 (续)
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.5 冲突检测命令
9.3.2.5.1 CHECK1 REQ
命令功能：冲突检测。
传输信道：发起方通过磁通道发送CHECK1 REQ 消息。
消息格式：SMF
消息内容：见表33
表33 CHECK1 REQ 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.5.2 CHECK1 RSP
命令功能：冲突响应。
传输信道：响应方通过 RF 通道发送[频点=freq2(CDC), 地 址
=addr1(CDC),freq2 和 addr1 的算
法定义见附录 B]。
消息格式：LMF
消息内容：见表34
GB/T 33736—2017
表34 CHECK1 RSP 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.6 连接确认消息
命令功能：连接确认。如果当前冲突检测配置为关闭，则发起方在建立连接之后持续发送
CHECK2 REQ 消息。 CHECK2 REQ
消息无需响应，仅用于响应方判断当前连接状态是否正常。
传输信道：发起方通过磁通道发送 CHECK2 REQ 消息。
消息格式：SMF
消息内容：见表35
表35 CHECK2 REQ 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
GB/T 33736—2017
9.3.2.7 长时等待命令
命令功能：响应方发送给发起方的长时交易等待 LTW 消息。
传输信道：响应方通过 RF 通道发送[频点=freq1(IDs),地 址
=addr2(IDs),freql 和 addr2 的算法
定义见附录 B]。
消息格式：LMF
消息内容：见表36
表36 LTW 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.8 关闭连接命令
9.3.2.8.1 CLOSE REQ
命令功能：发起方断开与响应方的连接。
传输信道：发起方通过 RF 通道发送[频点=freq1(IDs),地 址
=addr2(IDs),freq1 和 addr2 的算法
定义见附录 B]。
消息格式：LMF
消息内容：见表37
表37 CLOSE REQ 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
GB/T 33736—2017
表37(续)
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
9.3.2.8.2 CLOSE RSP
_
命令功能：响应方对CLOSE REQ 的响应确认。只有发起方在 CLOSE REQ
中指明需要响应方
对关闭连接进行确认(NeedResp=1) 时，响应方才做CLOSE RSP
响应确认，否则响应方在关闭连接后
即结束，不做CLOSE RSP 响应。
传输信道：响应方通过 RF 通道发送[频点=freq1(IDs),地 址
=addr2(IDs),freq1 和 addr2 的算法
定义见附录 B]。
消息格式：LMF
消息内容：见表38
表38 CLOSE RSP 消息
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 33736—2017
表 3 8 ( 续 )
|
|||
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
style="width:8.29335in;height:4.31332in" />
style="width:4.70663in;height:2.42in" />
style="width:4.73322in;height:2.35994in" />
GB/T 33736—2017
(资料性附录)
磁通道通信原理说明
磁场强度变化率调制如图 A.1
所示，符号“1”的场强变化率与符号“0”的场强变化率应为相反关
系，且变化率大小相等并保持恒定。磁通道数据编码符号率为4 kS/s,
每个符号周期为250 μs,Hp 为
发起方磁场信号强度峰值。磁通道信号符号的极性只与磁场强度变化率的方向有关，而与磁场强度变
化率的大小无关。磁场强度变化率的大小决定了磁场强度的峰值，磁场强度峰值的规范要求用于距离
控制。
图 A.1 磁场强度变化率调制
磁通道数据编码采用差分曼特斯特编码(DME), 如图 A.2
所示。每个数据位由2个符号组成的序
列表示，每个数据位的符号序列应为“10”或"01"。数据位“1"的符号序列与前一个数据位的符号序列相
反，数据位"0"的符号序列与前一个数据位的符号序列相同。
style="width:4.66666in;height:2.36676in" />
style="width:4.54662in;height:2.36676in" />
图 A.2 差分曼彻斯特编码
style="width:4.18003in;height:3.42672in" />
style="width:3.53339in;height:3.12664in" />
GB/T 33736—2017
磁通道调制解调及编解码原理如图 A.3
所示，发起方根据上述编码和调制原理，将磁通道数据转
换为磁场强度变化率调制信号。响应方通过磁感应线圈感应得到解调耦合电压信号，电压信号与磁场
信号的关系见式(A.1):
style="width:7.00668in;height:0.61336in" /> … … … … … …(A. 1)
式中：
V — 响应方耦合电压；
N — 响应方耦合线圈匝数；
— 响应方耦合想起面积；
style="width:0.9333in;height:0.55294in" />磁场强度的变化率；
μo— 空气中磁导率。
响应方从电压信号中得到磁通道信号符号序列，再根据差分曼彻斯特编码机制解码得到磁通道数
据。从图 A.3
中所列的两种情况可以看出，无论响应方采用正向耦合方式或是反向耦合方式，最终都
能得到正确的解码数据结果。
发起方
|
|
|---|
响应方正向耦合
style="width:4.84665in;height:3.38008in" />数 据
编码
符号
磁场强度
变化率调制
解调耦合
电压信号
符号
解 码
数据
响应方反向耦合
图 A.3 磁通道调制解调及编解码原理
GB/T 33736—2017
(规范性附录)
RF 通信参数计算
B.1 RF 频点计算方法
RF 频点计算方法如下：
以 N 为模对输入X 进行求余运算，即 (X)Mod N,其中N 是 RF
射频频率表支持的最大频点数
目，X 为不小于2字节的数据串。
计算得到的余数与频点的对应关系如表B.1～表 B.3 所示。
表 B.1 余数与频点的对应关系
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
|
|
|
|
|
|
表 B.2 工作频点表
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
表 B.3 冲突响应频点表
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
freq1 算法描述：
用途：用于计算工作频点。
计算方法：
1) X 为不小于2字节的数据串，取X 前2字节，记为 X2;
2) freq1(X)=(X2)Mod N,N=64;
3) 用 freql(X) 作为索引查表 B.2所示工作频点表，得到工作频点。
计算示例：
假设数据串 X:0x30110x39 \|10x23 \| \|0xa5, 其中" \| 目"表示"拼接"。
则 X2=0x30 \|10x39=12345
freq1(X)=(X2)Mod
N=(12345)Mod64=57,根据余数与频点对应关系，余数57对应频点
Chs, 查表 B.2,Ch 频率值为2458 MHz。
freq2 算法描述：
用途：用于计算冲突响应(CHECK1 RSP) 频点。
计算方法：
GB/T 33736—2017
1) X 为不小于2字节的数据串，取X 前2字节，记为 X2;
2) freq2(X)=(X2)Mod N,N=4;
3) 用 freq2(X) 作为索引查表B.3 所示冲突响应频点表，得到冲突响应频点。
计算示例：
假设数据串 X:0x30110x39 \|10x23 \| \|0xa5, 其中"目"表示"拼接"。
则 X2=0x301 \|0x39=12345
freq2=(X)Mod N=(12345)Mod4=1,根据余数与频点对应关系，余数1对应频点 Ch₂
, 查
表 B.3,Ch。 频率值为2466 MHz。
B.2 RF 通信地址计算方法
addr1 算法描述：
用途：用于计算激活响应(ATI) 和冲突响应(CHECK1 RSP)RF 通信地址。
计算方法：
addrl(X)=X[0] \| X[1] \| \| X[0] \|\| X[1] \|
\|0x00, 其中" \|"表示"拼接"。
其中 X 为2字节数据串。
说明：按照下列顺序将各字节组合成一个5字节的 RF 地址：X 第1字节、X
第2字节、X 第1字节的按位取反、X
第2字节的按位取反、最后一个字节补0。
通信 addr2算法描述：
用途：用于计算(除了 ATI 地址和CHECK1 RSP 地址之外的)其他所有 RF
通信地址。
计算方法：
addr2(X)=X[0] \| \| X[1] \| \|X[2] \| \| X[3] \|
\|X[4],其中" \|"表示"拼接"。
其中 X 为5字节数据串。
说明：按照下列顺序将 X 各字节组合成一个5字节的 RF 地址：X 第1字节、X
第2字节、X 第3字节、X 第 4 字
节、X 第5字节。
B.3 AID 计算方法
对于长度为n(2≤n≤14) 字节的IDm, 经过如下方式计算得到 AID:
1) 若 n≤8, 则在 IDm 后补0x00(n=8 时不用补0x00),补齐8字节，作为
Ka,K=Ka \| \| Ka (其 中Ka 表示对 Ka
的按位取反);若8\<n≤14, 则直接在 IDm 后补0x00,补齐16字节，作为 K。
2) 计算3DES[K,IDm] (见附录C.3,若 n\<8, 则在 IDm 后 补
0x00,补齐8字节作为被加密明 文；若 IDm 长度 n≥8, 则取IDm
前8字节作为被加密明文),得到8字节密文数据。
3) 取8字节密文数据前2字节，作为"AID"。
GB/T 33736—2017
(规范性附录)
密码相关算法定义
C.1 会话密钥产生方法
第一步：计算主密钥 K: 如果使用预置根密钥(即，CONNECT RSP 中确认的
RootKeyIndex 值不
为0),则16字节主密钥 K=K。④K;,(i≠0); 如果不使用预置根密钥(即，CONNECT
RSP 中确认的
RootKeyIndex 值为0),则16字节主密钥K=K。; 其中，16字节 K。 由 1 4 字 节
IDm (随机数)通过如图
C.1 所 示 方 式 扩 展 生 成 ：
style="width:11.56042in;height:4.15347in" />
16字节主密钥
图 C.1 IDm 扩展生成 K。 的方式
第二步：以响应方产生的8字节随机数 SDRand 为分散参数 X, 按 照C.2
所定义的"子密钥分散算
法"对第一步中计算得到的主密钥K 进行密钥分散，得到16字节子密钥K、。
第三步：使用K, 作为会话密钥。
C.2 子密钥分散算法
子密钥分散算法如图C.2 所示。
分散参数 X 不足8字节，则先右补0x80,如不足8字节则补0x00 至8字节。
分散参数 X 超过8字节，则取最右8字节。
GB/T 33736—2017
style="width:8.11997in;height:6.76676in" />主密钥左半 部分 (KL)
主密钥右半 部分 (KR)
主密钥左半 部分 (KL)
分散参数Y
DES
(加密)
DCS
(加密)
DES
(加密)
子密钥左半部分
分散参数X求反
DES
(加密)
DCS
(加密)
DES
(加密)
子密钥右半部分
主密钥左半
部分 (KL)
主密钥右半
部分 (KR)
主密钥左半
部分 (KL)
连接操作
16字节子密钥
图 C.2 子密钥分散算法
C.3 3DES 加解密算法
密钥长度为16字节[K=(KL \| \|KR)], 数据分组长度为8字节。
对于每个数据分组的加密算法如下：
Y=3DES[K,X]=DES(KL)[DES¹(KR)[DES(KL)[X]]]
解密算法如下：
Y=3DES-'[K,X]=DES- ¹(KL)[DES(KR)[DES-'(KL)[X]]]
每个分组的加解密过程如图 C.3 所示：
对于多个分组的加/解密过程，只需要将所有加/解密后的数据块依照原顺序连接在一起。
GB/T 33736—2017
style="width:2.97329in;height:4.9467in" />KI.
KR
KL
style="width:3.08011in;height:4.91326in" />Y Y
DES
(解密)
DES
(加密)
DES
(解密)
Y X
3DFS 加密 3DES 解密
K1.
KR
KL
图 C.3 3DES 加 解 密 过 程
C.4 数 据 报 文 加 解 密 方 法
对应用层数据报文 Payload采用ECB 模式的对称密码算法进行加解密。
按照如下步骤对数据报文进行加密：
第一步：用PLen(2 字节)表示明文数据的字节长度，在明文数据前加上 PLen,
产生新的数据块。
第二步：将该数据块分成以分组长度8字节为单位的数据块，表示为块1、块2、
…块 n。
第三步：如果最后(或唯一)的数据块的长度是分组长度，转到第四步；如果不足分组长度，则在其后
加入16进制数“80”,如果达到分组长度，则转到第四步，否则在其后加入16进制数"00"直到长度达到
分组长度。
第四步：按照图 C.4 所述的算法使用加密密钥对每一个数据块进行加密。
第五步：计算结束后，所有加密后的数据块依照原顺序连接在一起。
style="width:7.70694in;height:2.92708in" />
图 C.4 分 组 加 密
按照如下步骤对数据进行解密：
第一步：将该数据块分成以分组长度8字节为单位的数据块，表示为块1、块2、
…块 n。
第 二 步 ： 按 照 图 C.5 所 述 的 算 法 使 用 解 密 密 钥 对 每 一 个
数 据 块 进 行 解 密 。
GB/T 33736—2017
第三步：计算结束后，所有解密后的数据块依照原顺序连接在一起。
第四步：前2个字节为 PLen, 从第3字节起，取前PLen 字节数据作为明文输出。
style="width:7.66736in;height:2.98889in" />
图 C.5 分 组 解 密
C.5 MAC 算 法
MAC 的产生使用以下算法：
第一步：将一个8个字节长的初始值(Initial Vector)设定为16进制的"0x
00000000000000
00"。
第二步：将所有的输入数据按指定顺序连接成一个数据块。
第三步：将连接成的数据块分割为8字节长的数据块组，标识为D1,D2,D3,D4
等。分割到最后，
余下的字节组成一个长度小于或等于8字节的最后一块数据块。
第四步：如果最后一个数据块长度为8字节，则在此数据块后附加一个8字节长的数据块，附加的
数据块为：16进制的“0x 8000000000000000”。
如果最后一个数据块长度小于8字节，则该数据块
的最后填补一个值为16进制“0x80”的字节。如果填补之后的数据块长度等于8字节，则跳至第五步。
如果填补之后的数据块长度仍小于8字节，则在数据块后填补16进制"0x00"的字节至数据块长度为
8字节。
第五步：MAC 的产生是通过上述方法产生的数据块组，由 KO
进行加密运算，加密算法 DEA 使用
DES。MAC 算 法 如 图C.6 所 示 。
style="width:3.09333in" />
33736—2017
style="width:8.60694in;height:4.44028in" />
说明：
I= 输入
DEA(e)= 数据加密算法(加密模式) DEA(d)= 数据加密算法(解密模式)
D= 数据块
第六步：最终值的左4字节为 MAC。
O= 输出
KML/R=MAC 过程密钥左/右半部分
④=异或运算
图 C.6 MAC 算 法
更多内容 可以 GB-T 33736-2017 手机支付 基于2.45GHz RCC 限域通信 技术的非接触射频接口技术要求. 进一步学习
